Proof why "rebuild on each Java version" pattern is totally wrong: The CI. The JARs should be built on controlled Java + Maven version and then test performed on matrix, as right now, what you can use is really matrix minimum and that is outright silly.

Proof why "rebuild on each Java version" pattern is totally wrong: The CI. The JARs should be built on controlled Java + Maven version and then test performed on matrix, as right now, what you can use is really matrix minimum and that is outright silly.

It is easier configuration ...

Thanks!

Still, the reason I dislike this is that consumer may rightfully ask "and what Java was used to release this?" -- as we basically make a feature depend on Java version we use to release. The proposed solution (use one version to build and enforce it) makes the presence of feature clear, and not kinda optional-ish.

Also, if someone releases this library and by mistake use Java 17 or 11 (as library is Java 8+), nothing will happen: no big red alarm will ring, and the only way to figure out what happened is to inspect the release output Java...

Or simply, faster switch to Java 21

I added check in release profile to use 21+, so we will not have a mistake

We can merge it ...
I will look at using many deprecated methods from commons-io .... and next release it